home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000099_news@columbia.edu _Wed Oct 25 18:39:56 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA17891
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Wed, 25 Oct 2000 18:39:56 -0400 (EDT)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA11923
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 25 Oct 2000 18:39:56 -0400 (EDT)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id SAA23392
  10.     for kermit.misc@watsun.cc.columbia.edu; Wed, 25 Oct 2000 18:38:27 -0400 (EDT)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: Luiz Geraldo Silva Braz <braz@i2.com.br>
  13. Subject: Re: log of a kermit comunication
  14. Date: Wed, 25 Oct 2000 20:34:21 -0200
  15. Organization: POP-MG
  16. Message-ID: <Pine.LNX.3.96.1001025195005.17762B-100000@atlanta.i2.com.br>
  17. To: kermit.misc@columbia.edu
  18.  
  19.  
  20. OK. This is not a kermit conversation. :-)
  21.  
  22. But I supose that this software was built by someone that
  23. has based in kermit to do his work.
  24.  
  25. Analizing many logs I have recorded I supose that probably 
  26. this (not kermit but) kermit-like implementation uses 3 
  27. character of checksum.
  28. And more: If I discover how they have calculated their kermit-like
  29. checksum I solve my problem. And my job. :-)
  30.  
  31. I know that kermit especification suport a there character
  32. checksum based in crc-16. Althougth the paper I have read it didn't 
  33. mention clearly how I should calculate the 3 checksum character 
  34. of the packet. 
  35.  
  36. Where could I get a complete description of kermit that include 
  37. the 3-character checksum calculation?
  38.  
  39. I am suposing that the correct algoritm is something like 
  40. the lines above. 
  41.  
  42.    LD   = length of data
  43.    LC   = length of Checksum (three in this case)
  44.    TL   = LD + LC + 2  (2 because of the sequetial 
  45.                        and packet type characters) 
  46.    
  47.    TL32 = TL + 32 (Total length excess-32) 
  48.    S    = Sequencial number of the packet
  49.    S32  = S + 32
  50.    T    = caracter that represents the type of packet
  51.    D    = data to be transmited
  52.  
  53.    unsigned short int CRC = crc16(concat(TL32,S32,T,D))
  54.    
  55.    C1 = (CRC shr 12) and $0F   (1st. character)  
  56.    C2 = (CRC shr 6) and $3F    (2nd. character)
  57.    C3 = CRC and $3f            (guess you)
  58.  
  59. Is it the method?
  60.  
  61. Thanks in advance.
  62.  
  63. Luiz Braz
  64. braz@i2.com.br
  65.  
  66.  
  67. On 25 Oct 2000, Frank da Cruz wrote:
  68.  
  69. > In article <Pine.LNX.3.96.1001024185713.5485B-100000@atlanta.i2.com.br>,
  70. > Luiz Geraldo Silva Braz  <braz@i2.com.br> wrote:
  71. > :    
  72. > :    This is a log of kermit comunication that I need to decode.
  73. > :    The big questions are:
  74. > :  
  75. > :     1) What king of command could generate the first string
  76. > :        sent to the kermit server?
  77. > :        
  78. > :              #A&  D#C"@%<ENTER> (see the log above)
  79. > :  
  80. > :     2) Would this entire comunication be the result of just
  81. > :        one c-kermit command or a lot of commands? 
  82. > :        What would be this (these) commands?
  83. > :  
  84. > :     I intend to create a script (using expect) to interact
  85. > :     with c-kermit and automate this kind of comunication.
  86. > :  
  87. > :     I have inserted some coments (***) inside the log.
  88. > :     
  89. > :     Each set of packets has the sender ID ( "1>" to client and "0>"
  90. > :     to the server) and two representations of the data sent in 2 
  91. > :     columns.
  92. > : 
  93. > :     Some non-printbles caracteres are represented by "." at the 
  94. > :     rigth column. In the left column appears the Hex code of each 
  95. > :     char and the simbol of the non-printblesi char. 
  96. > : 
  97. > :     Thanks in advance.
  98. > : 
  99. > : Luiz Braz
  100. > : braz@i2.com.br
  101. > : PS: Sorry about the errors. This is the first message I have 
  102. > :     wroten in English. :-) 
  103. > : 
  104. > : >-------------------------------------------------------------------------
  105. > : *** Estabilishing the connection. 817371001 is just the phone number. :-)
  106. > : 1> 0000: 41 54 44 54 30 77 30 33 31 38 31 37 33 37 31 30    ATDT0318173710
  107. > :          A  T  D  T  0  w  0  3  1  8  1  7  3  7  1  0  
  108. > :    0010: 30 31 0D                                           01.
  109. > :          0  1  ^M 
  110. > : 
  111. > : 0> 0000: 0D 0A 43 4F 4E 4E 45 43 54 20 39 36 30 30 2F 41    ..CONNECT 9600/A
  112. > :          ^M ^J C  O  N  N  E  C  T  bs 9  6  0  0  /  A  
  113. > :    0010: 52 51 2F 56 33 32 2F 4C 41 50 4D 2F 56 34 32 42    RQ/V32/LAPM/V42B
  114. > :          R  Q  /  V  3  2  /  L  A  P  M  /  V  4  2  B  
  115. > :    0020: 49 53 0D 0A                                        IS..
  116. > :          I  S  ^M ^J 
  117. > : 
  118. > This is the CONNECT message from the modem.
  119. > 
  120. > : 1> 0013: 23 41 26 20 20 44 23 43 22 40 25 0D                #A&  D#C"@%.
  121. > :          #  A  &  bs bs D  #  C  "  @  %  ^M 
  122. > : 
  123. > The format of a Kermit packet is:
  124. > 
  125. >   MARK LEN SEQ TYPE DATA CHECK
  126. > 
  127. > Where:
  128. > 
  129. >   MARK  is a control character, Ctrl-A by default.
  130. >   LEN   is a one-byte excess-32 length field.
  131. >   SEQ   is a one-byte excess-32 sequence number.
  132. >   TYPE  is a one-byte packet type.
  133. >   DATA  is 0 or more bytes of data.
  134. >   CHECK is the block check.
  135. > 
  136. > Let's assume that your protocol dump is printing Ctrl-A as "#A".  In
  137. > that case:
  138. > 
  139. >   LEN   = '&' = ASCII 38 - 32 = 6.
  140. >   SEQ   = ' ' = ASCII 32 = 32 = 0.
  141. >   TYPE  = ' ' which is not a valid Kermit packet type.
  142. >   DATA  = D#C"@
  143. >   CHECK = %
  144. > 
  145. > So the MARK is wrong, the LEN is wrong, and the TYPE is wrong.  No Kermit
  146. > program would recognize this as a valid packet.
  147. > 
  148. > If, however, the two spaces are a mistake of your recording tool, and really
  149. > there is only one space, then we have:
  150. > 
  151. >   LEN   = '&' = ASCII 38 - 32 = 6.
  152. >   SEQ   = ' ' = ASCII 32 = 32 = 0.
  153. >   TYPE  = 'D' (Data)
  154. >   DATA  = #C"@
  155. >   CHECK = %
  156. > 
  157. > It's closer, but still the length is wrong (6 instead of 7).  But if we
  158. > assume that #A is really Ctrl-A, then maybe #C really is Ctrl-C, in which
  159. > case the length would be correct.  But the block check is still wrong.
  160. > 
  161. > : *** The server answers with an ack packet (Y) and a unknown M-package. 
  162. > :     What kind of package is it? I did't see it at the kermit 
  163. > :     protocol description I have?
  164. > : 0> 0024: 23 41 25 20 20 59 2A 24 33 0D 23 41 53 20 5F 4D    #A%  Y*$3.#AS _M
  165. > :          #  A  %  bs bs Y  *  $  3  ^M #  A  S  bs _  M  
  166. > :
  167. > This too has a superficial resemblence to a Kermit packet, if we assume that
  168. > #A really is Ctrl-A and the two blanks are really one blank:
  169. > 
  170. >   LEN   = '%' = ASCII 37 - 32 = 5.
  171. >   SEQ   = ' ' = ASCII 32 = 32 = 0.
  172. >   TYPE  = 'Y' (ACK)
  173. >   DATA+CHECK = *$#
  174. > 
  175. > But the block check isn't right, no matter how you interpret it.
  176. > 
  177. > [ ... and so on ... ]
  178. > 
  179. > : and the result of the command continues to come in sequences 
  180. > : of three packages... (see the big questions I have made at the
  181. > : begining of this mesage.) 
  182. > : 
  183. > There is some resemblence to Kermit protocol, but it isn't really Kermit
  184. > protocol.  The proper sequence of messages is not there, the packets are not
  185. > in the right format, the block checks are not correct.  And this is even
  186. > allowing for some aftereffects of your recording tools.
  187. > 
  188. > - Frank
  189. > 
  190. > 
  191.